Einige kleine Anmerkungen zum Flashen der neuen SW Version 0.13b:



Vorkompilierte HEX-Files:
=========================
Wer sich das Kompilieren des Source-Codes nicht zutraut, kann auch ein vorkompiliertes HEX-File aus dem neuen ZIP-File auf den Controller flashen. Hier gilt unbedingt zu beachten: Wer bisher KEINE Probleme mit dem Funkuhrempfang/Debugging hatte, sollte unbedingt dasjenige HEX-File verwenden, das als "Wordclock13b_OHNE_OSCCAL.hex" betitelt ist. Damit wird der bisher verwendete Kalibrationswert des Mikrocontrollers verwendet, der vom Hersteller bereits so eingestellt wurde und der Funkuhr Empfang / das Debugging funktioniert nach wie vor (mehr Infos hierzu weiter unten in diesem Readme). Wer allerdings Probleme hatte, kann gerne verschiedene HEX-Files durchprobieren, die in einem "vernünftigen" Kalibrationsbereich liegen und jeweils prüfen, ob der passende Wert für einen dabei ist (auch hierzu siehe unten). Anmerkung: Der Funkempfang funktioniert grundsätzlich nur mit AUSgeschalteten LEDs (ausser ihr habt einen super-duper Spannungsfilter oder einen ultrastabilen DCF-Empfänger ;-) ). Der Empfang dauert mindestens 2, typisch jedoch 3-4Minuten, bis die Uhrzeit stimmt. Deshalb die LEDs bitte jeweils erst frühestens nach ca. 5 Min. wieder einschalten, sonst beginnt das Einlesen der Funkzeit allenfalls von vorne.



Vorkompilierte EEPROM-Daten verwenden:
======================================
Im ZIP-File ist ebenfalls ein ".eep" File enthalten. Dies ist der Inhalt meiner eigenen Wordclock (deutsch 3-sprachig, mit Ambi, mit DCF77, DX-Fernbedienung mit im Wiki empfohlener Tastenbelegung und "vernünftigen" Helligkeiten mit einem LDR-Pullup von 150kOhm). Ich habe festgestellt, dass das programmieren dieser EEPROM-Daten teils nicht 100%ig funktioniert, ich musste manchmal(?) die Tasten der Fernbedienung trotz Programmieren des Files nochmals von Hand einlernen, da die Uhr sonst nicht mehr reagierte. Keine Ahnung wieso, macht eigentlich keinen Sinn... Es kann also sein, dass das Programmieren dieses .eep Files nicht zu 100% funktioniert und ihr ebenfalls nochmals einlernen müsst. (Betrifft auch Helligkeitsanpassung der Uhr etc.) Kaputt machen könnt ihr indes nichts, wenn die Uhr die Datenstruktur des EEPROMs nicht als gültig erkennt, werden sämtlichen Daten im EEPROM neu angelegt -> Tasten neu einlesen und Helligkeit wieder anpassen, dann ist wieder alles ok.



EESAVE-Fuse:
============
Es empfiehlt sich, vor dem Flashen der neuen Software bei den Fuses "EESAVE" zu aktivieren (falls nicht so oder so bereits so gesetzt). Damit sollten dann die Fuses für den Atmega168 die folgenden HEX-Werte enthalten:
     EXTENDED:  0xFD
     HIGH:      0xD4
     LOW:       0xE2
Auf diese Art und Weise müssen zukünftig die Tasten der Fernbedienung und die Helligkeitsanpassungen etc. nicht bei jedem neuen Neuflashen des Controllers wieder neu eingelernt werden. (Achtung: Beim Updaten von 0.13a auf 0.13b wird dies leider einmalig trotzdem nötig sein, da neu einige weitere Werte im EEPROM gespeichert werden als bisher, somit ist die Grösse des Datenstructs im EEPROM nicht mehr gleich aufgebaut wie bisher. Dies muss nach dem Softwareupdate wie erwähnt natürlich nur einmalig wieder gemacht werden.)




Probleme beim Funkuhrempfang (DCF77) oder/und beim seriellen Debuggen:
======================================================================
Wer so wie ich bisher Probleme mit dem DCF77-Funkempfang hatte (auch bei ausgeschalteten LEDs der Uhr!), oder/und beim Debuggen mit der seriellen Schnittstelle bei 9600baud eigenartige Zeichen empfing, könnte diese Problematik höchstwahrscheinlich auf folgende Art und Weise beheben: Der Atmega Controller läuft bei der Wordclock mit seinem internen RC-Oszillator, welcher eine relativ grosse Frequenztoleranz von ca. 10% aufweisen kann. Dadurch liegen dann die Pulslängen des DCF77-Empfängers asserhalb der in der Software festgelegten Pulslängen und ein Funkuhr-Empfang ist nicht mehr möglich. Die Problematik der Frequenztoleranzen zeigen sich auch beim Debuggen über die serielle Schnittstelle. Statt mit 9600baud muss dann z.B. PC-seitig eine Übertragung von 10200baud oder ein anderer Wert um 9600 rum eingestellt werden, damit die Debugdaten auf dem PC lesbar werden. Die Frequenz des Mikrocontrollers lässt sich mit dem Register "OSCCAL" im Atmega korrigieren. Von meinen beiden Uhren, die momentan bei mir zuhause sind, drifteten diese OSCCAL-Werte bereits erstaunlich weit auseinander. Es gibt zwei Möglichkeiten, den korrekten Wert für OSCCAL zu finden:

a) MIT UART-USB-WANDLER: Daten der seriellen Schnittstelle anschauen. Sie zeigen die Pausenlängen zwischen den DCF77-Pulsen. Diese Zahlen sollten alle im Bereich zwischen 75 und 96 liegen. Nun soll OSCCAL so lange verändert werden, bis diese Werte mit gleich viel Reserve nach oben und unten herauskommen. Sind die seriellen Ausgabewerte eher zu hoch, muss OSCCAL verringert, ansonsten vergrössert werden.

b) MIT UART-USB-WANDLER: Man stellt eine serielle Debug-Verbindung zum PC mit genau 9600baud her und korrigiert OSCCAL so lange nach oben und nach unten, bis man jeweils keine saubere Debug-Ausgabe mehr auf dem PC erhält. Der Mittelwert zwischen den beiden Extremwerten wäre dann der exakte Kalibrationswert.

c) MIT OSZILLOSKOP: Man misst mit einem Oszilloskop die Länge der seriellen Datenbits. Sind die Bitlängen zu kurz, muss der OSCCAL Wert vermindert werden, sind sie zu lang, erhöht man den OSCCAL Wert, bis es passt. Bei 9600baud sollte die kürzest mögliche "1" oder "0"-Phase (also von einer steigenden zur fallenden Flanke bei der kürzest sichtbaren, gleichbleibenden Spannung) 1/9600bps = 104.2us betragen.

Anmerkung: In den Sources und den vorkompilierten hex Files in diesem ZIP-Archiv ist die Debugschnittstelle für den DCF77-Empfang aktiviert, so dass auf der seriellen Schnittstelle entsprechend dauernd Daten ausgegeben werden.



Ganz liebe Grüsse und euch allen viel Spass mit der "neuen" Software :-)
Simon